(Dialog) How do I debug a 40tude "socket error" (what's a socket error?)

[Ronald]

Dialog is failing on a Neodome account setup that used to work.
Posting article failed: Socket Error # 0; (nameofserver username ok)(Finished)
Socket Error # 0; (nameofserver username ok)(Finished)

The stunnel.conf file has the same boilerplate setup as it always had.
That boilerplate stunnel.conf is this (which used to work for Neodome).
[neodome]
client = yes
accept = 127.0.0.1:55555
connect = news.neodome.net:563
verify = 0
verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.neodome.net
OCSPaia = yes

That same boilerplate stunnel.conf works for other encrypted servers.
Just not Neodome.

40TudeDialog is set up for that user as any other setup would be.
Host: 127.0.0.1
Port: 55555
SSL: unchecked
Username: abcdefg
Password: xxxxxxx
Allwd. conn.: 2
Use pipelining (unchecked)

I set the log level to "0 - All debug messages" by right clicking on
"Connections" at the bottom right corner of the Windows Dialog GUI.

Then I copied the section of the files in Program Files under "logs".

0 25674390: Creating worker thread: Sending message to news.software.readers neodome Username ok1
0 25674390: FDATA: Opening 1
0 25674390: FDATA: Reading itemcount 3
0 25674390: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2572
3 25674390: Sending message to news.software.readers (Started) [$0000250C]
1 25674390: NNTP slot used by this thread: neodome Username ok1 [$0000250C]
3 25674390: Connecting to NNTP 127.0.0.1:60569 [$0000250C]
1 25675500: Reindexing (Order: 3, no filtering) of group 1 with 2574 articles took 16 ms
0 25675500: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2572
0 25675500: FDATA: Regular update PAK - ChangeCount: 0
0 25675500: FDATA: adding GroupKey: 1 ArticleKey: 2573
0 25675500: FDATA: Regular update PAK - ChangeCount: 1
0 25675515: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571
0 25675515: FontFB: No non-ASCII characters found; Using default font
0 25675515: FontFB: Using font "Arial" which is missing 0 glyphs.
0 25675515: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571
0 25675515: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571
0 25675531: FontFB: No non-ASCII characters found; Using default font
0 25675531: FontFB: Using font "Arial" which is missing 0 glyphs.
0 25675531: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571
0 25675531: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571
0 25675531: FontFB: No non-ASCII characters found; Using default font
0 25675531: FontFB: Using font "Arial" which is missing 0 glyphs.
0 25675546: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571
0 25675484: !Quit (Finished) [$0000250C]
5 25675484: Socket Error # 0; (neodome Username ok) (Finished) [$0000250C]
0 25675484: KillNNTP entered for: neodome Username ok1 (Finished) [$0000250C]
0 25675484: KillNNTP left for: neodome Username ok1 (Finished) [$0000250C]
0 25675484: KillNNTP entered for: neodome Username ok1 (Finished) [$0000250C]
0 25675484: KillNNTP left for: neodome Username ok1 (Finished) [$0000250C]
5 25675484: Posting article failed: Socket Error # 0; (neodome Username ok) (Finished) [$0000250C]
1 25675500: Sending message to news.software.readers (Finished) (Finished) [$0000250C]
0 25676328: TFlushBodiesThread started with ThreadID: $16A0
1 25678328: Flushing body db
0 25678328: FDATA: Updating PAK, number of subfiles: 29
0 25678328: FDATA: Writing itemcount 3
0 25678328: FDATA: Closing 1
1 25679687: Main window close query
1 25679750: Main window destroy called - Goodbye
0 25679765: FDATA: destroying; Changecount: 0
1 25679765: Flushing group and server list

How can I further debug this socket error before contacting Neodome admins?
(What is a Dialog socket error anyway?)

[Ronald]

When cleaning up the log to make it easier for you to read, I made a
minor mistake in simplifying the port number and noticed it too late.

Here's the corrected log so you don't waste time debugging the prior log.

0 25674390: Creating worker thread: Sending message to news.software.readers neodome Username ok1
0 25674390: FDATA: Opening 1
0 25674390: FDATA: Reading itemcount 3
0 25674390: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2572
3 25674390: Sending message to news.software.readers (Started) [$0000250C]
1 25674390: NNTP slot used by this thread: neodome Username ok1 [$0000250C]

3 25674390: Connecting to NNTP 127.0.0.1:55555 [$0000250C]

The line I don't understand is that the error is a Dialog "socket error".
What's that?

[Bernd Rose]

On Sat, 6th Jan 2024 23:08:44 -0500, Ronald wrote:

> 1 25674390: NNTP slot used by this thread: neodome Username ok1 [$0000250C]
> 3 25674390: Connecting to NNTP 127.0.0.1:55555 [$0000250C]

[...]

> 0 25675484: !Quit (Finished) [$0000250C]
>

> The line I don't understand is that the error is a Dialog "socket error".
> What's that?

A socket is a dedicated connection established by the OS between a program
and an IP-address:port combination. Several such sockets can exist in
parallel at any certain time, just not with the same parameters.

"Socket error # 0" isn't a normal Socket error number. It will be returned
by the Indy network functions (a Delphi network library used by Dialog),
when no connection could be established, at all.

From above information it seems, you set up your connection to the Neodome
server inside Dialog to connect to localhost (127.0.0.1) on port 55555.
User name and password for the Neodome server have to be entered inside the
Dialog connection settings, as well. You must /not/ tick on the SSL box,
though, because with above parameters you most likely want to use a more
up-to-date program for managing the encryption.

You are probably using sTunnel as an intermediate for encrypted connections.
With above parameters you need to set up sTunnel to accept local connections
from port 55555 and forward them encrypted to the Neodome NNTP server:

[Neodome]
client = yes
accept = localhost:55555
connect = news.neodome.net:563

verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.neodome.net
OCSPaia = yes

Please check, if sTunnel is running at all. And if the connection parameters
are set correctly. (Especially, that no 2 connection sections using the same
/internal/ port number [55555 in this case].) If this all seems okay, check
the sTunnel log file for further information.

HTH.
Bernd

[Bernd Rose]

On Sat, 6th Jan 2024 23:08:44 -0500, Ronald wrote:

> 1 25674390: NNTP slot used by this thread: neodome Username ok1 [$0000250C]
> 3 25674390: Connecting to NNTP 127.0.0.1:55555 [$0000250C]

[...]

> 0 25675484: !Quit (Finished) [$0000250C]
> 5 25675484: Socket Error # 0; (neodome Username ok) (Finished) [$0000250C]

[...]

> The line I don't understand is that the error is a Dialog "socket error".
> What's that?

A socket is a dedicated connection established by the OS between a program
and an IP-address:port combination. Several such sockets can exist in
parallel at any certain time, just not with the same parameters.

"Socket error # 0" isn't a normal Socket error number. It will be returned
by the Indy network functions (a Delphi network library used by Dialog),
when no connection could be established, at all.

From above information it seems, you set up your connection to the Neodome
server inside Dialog to connect to localhost (127.0.0.1) on port 55555.
User name and password for the Neodome server have to be entered inside the
Dialog connection settings, as well. You must /not/ tick on the SSL box,
though, because with above parameters you most likely want to use a more
up-to-date program for managing the encryption.

You are probably using sTunnel as an intermediate for encrypted connections.
With above parameters you need to set up sTunnel to accept local connections
from port 55555 and forward them encrypted to the Neodome NNTP server:

[Neodome]

client = yes
accept = localhost:55555
connect = news.neodome.net:563

verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.neodome.net
OCSPaia = yes

[Ronald]

On Sun, 7 Jan 2024 09:10:13 +0100, Bernd Rose <b.rose...@arcor.de> wrote

> A socket is a dedicated connection established by the OS between a program
> and an IP-address:port combination. Several such sockets can exist in
> parallel at any certain time, just not with the same parameters.
>
> "Socket error # 0" isn't a normal Socket error number. It will be returned
> by the Indy network functions (a Delphi network library used by Dialog),
> when no connection could be established, at all.

Thanks for that information as Stunnel is working with other encrypted nntp
news servers without the socket error that only Neodome is reporting.

The strange thing is the Neodome stunnel entry was working for about a year
and there are no conflicts in the port (55555) arbitrarily assigned as I've
changed the port multiple times (in both Dialog & in stunnel.conf of course)
and no other nntp server is using the same port either.

> From above information it seems, you set up your connection to the Neodome
> server inside Dialog to connect to localhost (127.0.0.1) on port 55555.
> User name and password for the Neodome server have to be entered inside the
> Dialog connection settings, as well. You must /not/ tick on the SSL box,
> though, because with above parameters you most likely want to use a more
> up-to-date program for managing the encryption.

Yep. All that is set exactly as you said, and it used to work for Neodome.
It still works for other encrypted news servers - but just not Neodome.

> You are probably using sTunnel as an intermediate for encrypted connections.
> With above parameters you need to set up sTunnel to accept local connections
> from port 55555 and forward them encrypted to the Neodome NNTP server:
>
> [Neodome]
> client = yes
> accept = localhost:55555
> connect = news.neodome.net:563
> verifyChain = yes
> CAfile = ca-certs.pem
> checkHost = news.neodome.net
> OCSPaia = yes

My stunnel.conf is only very slightly different, as shown below.
[neodome]
client = yes
accept = 127.0.0.1:55555
connect = news.neodome.net:563
verify = 0

verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.neodome.net
OCSPaia = yes

The only difference is I have a "verify = 0" which I will comment out.
And I use "127.0.0.1" instead of "localhost" which should not matter.

> Please check, if sTunnel is running at all.

Stunnel is definitely running as I post with other servers using it.

Plus the icon in the hardware section of the taskbar will be green when
it's OK, then blue when being used, and red if there's a failure.

It's green.

> And if the connection parameters
> are set correctly. (Especially, that no 2 connection sections using the same
> /internal/ port number [55555 in this case].) If this all seems okay, check
> the sTunnel log file for further information.

To get a clean log out of Stunnel, I killed and restarted it.
This shows it's ready to take connections.
2024.01.07 02:18:11 LOG5[main]: stunnel 5.69 on x64-pc-mingw32-gnu platform
2024.01.07 02:18:11 LOG5[main]: Compiled/running with OpenSSL 3.0.8 7 Feb 2023
2024.01.07 02:18:11 LOG5[main]: Threading:WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI
2024.01.07 02:18:11 LOG5[main]: Reading configuration from file C:\Program Files\stunnel\config\stunnel.conf
2024.01.07 02:18:11 LOG5[main]: UTF-8 byte order mark detected
2024.01.07 02:18:11 LOG5[main]: FIPS mode disabled
2024.01.07 02:18:32 LOG5[main]: Configuration successful

This is what happens when I post to another server (not neodome).
2024.01.07 02:34:17 LOG5[0]: Service [eternal] accepted connection from 127.0.0.1:55554
2024.01.07 02:34:20 LOG5[0]: s_connect: connected 135.181.20.170:563
2024.01.07 02:34:20 LOG5[0]: Service [eternal] connected remote server from 10.211.1.145:60382
2024.01.07 02:34:24 LOG5[0]: OCSP: Connecting the AIA responder "http://r3.o.lencr.org"
2024.01.07 02:34:27 LOG5[0]: s_connect: connected 23.2.16.105:80
2024.01.07 02:34:30 LOG5[0]: OCSP: Certificate accepted
2024.01.07 02:34:30 LOG5[0]: Certificate accepted at depth=0: CN=news.eternal-september.org
2024.01.07 02:34:44 LOG3[0]: SSL_read: ssl/record/rec_layer_s3.c:321: error:0A000126:SSL routines::unexpected eof while reading
2024.01.07 02:34:44 LOG5[0]: Connection reset: 358 byte(s) sent to TLS, 388 byte(s) sent to socket

This is what happens when I post to the neodome server.
2024.01.07 02:18:55 LOG5[0]: Service [neodome] accepted connection from 127.0.0.1:55555
2024.01.07 02:19:00 LOG5[0]: s_connect: connected 95.216.243.224:563
2024.01.07 02:19:00 LOG5[0]: Service [neodome] connected remote server from 10.211.1.145:60371
2024.01.07 02:19:01 LOG4[0]: CERT: Pre-verification error: self-signed certificate
2024.01.07 02:19:01 LOG4[0]: Rejected by CERT at depth=0: O=Neodome, CN=neodome.net, emailAddress=ad...@neodome.net
2024.01.07 02:19:01 LOG3[0]: SSL_connect: ssl/statem/statem_clnt.c:1889: error:0A000086:SSL routines::certificate verify failed
2024.01.07 02:19:01 LOG5[0]: Connection closed/reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket

This is the Dialog log file when I post using eternal september with Stunnel.
0 43532453: Creating worker thread: Sending message to alt.test username
0 43532453: FDATA: Opening 1
0 43532468: FDATA: Reading itemcount 6
0 43532468: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2579
3 43532453: Sending message to alt.test (Started) [$00002754]
1 43532453: NNTP slot used by this thread: username [$00002754]
3 43532468: Connecting to NNTP 127.0.0.1:55556 [$00002754]
0 43548968: 200 news.eternal-september.org InterNetNews NNRP server INN 2.8.0 (20231205 snapshot) ready (posting ok) [$00002754]
0 43548968: !MODE READER [$00002754]
0 43550859: 200 news.eternal-september.org InterNetNews NNRP server INN 2.8.0 (20231205 snapshot) ready (posting ok) [$00002754]
3 43550859: Connected to NNTP 127.0.0.1:55556 [$00002754]
3 43550859: Logging in to NNTP 127.0.0.1:55556 [$00002754]
0 43550859: !AUTHINFO USER ****** [$00002754]
0 43552218: 381 Enter password [$00002754]
0 43552218: !AUTHINFO PASS ********* [$00002754]
0 43554687: 281 Authentication succeeded [$00002754]
3 43554687: Posting message to NNTP server [$00002754]
0 43554687: !POST [$00002754]

This is the Dialog log file when I post using neodome with Stunnel.

0 25674390: Creating worker thread: Sending message to news.software.readers neodome Username ok1
0 25674390: FDATA: Opening 1
0 25674390: FDATA: Reading itemcount 3
0 25674390: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2572
3 25674390: Sending message to news.software.readers (Started) [$0000250C]

1 25674390: NNTP slot used by this thread: neodome Username ok1 [$0000250C]
3 25674390: Connecting to NNTP 127.0.0.1:55555 [$0000250C]

1 25675500: Reindexing (Order: 3, no filtering) of group 1 with 2574 articles took 16 ms
0 25675500: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2572
0 25675500: FDATA: Regular update PAK - ChangeCount: 0
0 25675500: FDATA: adding GroupKey: 1 ArticleKey: 2573
0 25675500: FDATA: Regular update PAK - ChangeCount: 1
0 25675515: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571
0 25675515: FontFB: No non-ASCII characters found; Using default font
0 25675515: FontFB: Using font "Arial" which is missing 0 glyphs.
0 25675515: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571
0 25675515: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571
0 25675531: FontFB: No non-ASCII characters found; Using default font
0 25675531: FontFB: Using font "Arial" which is missing 0 glyphs.
0 25675531: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571
0 25675531: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571
0 25675531: FontFB: No non-ASCII characters found; Using default font
0 25675531: FontFB: Using font "Arial" which is missing 0 glyphs.
0 25675546: FDATA: Extracting body of GroupKey: 1 ArticleKey: 2571

0 25675484: !Quit (Finished) [$0000250C]
5 25675484: Socket Error # 0; (neodome Username ok) (Finished) [$0000250C]

0 25675484: KillNNTP entered for: neodome Username ok1 (Finished) [$0000250C]
0 25675484: KillNNTP left for: neodome Username ok1 (Finished) [$0000250C]
0 25675484: KillNNTP entered for: neodome Username ok1 (Finished) [$0000250C]
0 25675484: KillNNTP left for: neodome Username ok1 (Finished) [$0000250C]
5 25675484: Posting article failed: Socket Error # 0; (neodome Username ok) (Finished) [$0000250C]
1 25675500: Sending message to news.software.readers (Finished) (Finished) [$0000250C]
0 25676328: TFlushBodiesThread started with ThreadID: $16A0
1 25678328: Flushing body db
0 25678328: FDATA: Updating PAK, number of subfiles: 29
0 25678328: FDATA: Writing itemcount 3
0 25678328: FDATA: Closing 1
1 25679687: Main window close query
1 25679750: Main window destroy called - Goodbye
0 25679765: FDATA: destroying; Changecount: 0
1 25679765: Flushing group and server list

The two errors (one in Dialog's log and the other in Stunnel's log) are:

Dialog error:

5 25675484: Socket Error # 0; (neodome Username ok) (Finished) [$0000250C]

0 25675484: KillNNTP entered for: neodome Username ok1 (Finished) [$0000250C]

Stunnel error:
2024.01.07 02:19:01 LOG4[0]: CERT: Pre-verification error: self-signed certificate
2024.01.07 02:19:01 LOG4[0]: Rejected by CERT at depth=0: O=Neodome, CN=neodome.net, emailAddress=ad...@neodome.net
2024.01.07 02:19:01 LOG3[0]: SSL_connect: ssl/statem/statem_clnt.c:1889: error:0A000086:SSL routines::certificate verify failed

In a minute I will try it again by removing that one line (verify = 0)
in the stunnel.conf file for Neodome, but does that look like to you
that the certificate for Neodome is having the problem?

Or does it look like a problem on my side?

[Ronald]

On Sun, 7 Jan 2024 03:53:10 -0500, Ronald wrote:

> In a minute I will try it again by removing that one line (verify = 0)
> in the stunnel.conf file for Neodome, but does that look like to you
> that the certificate for Neodome is having the problem?

I commented out the "verify = 0" stunnel.conf line, but it still failed.
It just failed faster.

Stunnel.conf
[Neodome]
client = yes

accept = 127.0.0.1:55555
connect = news.neodome.net:563
; verify = 0

; (verify was set to 0 because it's a self-signed certificate)

verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.neodome.net
OCSPaia = yes

Dialog log:
5 44896390: Socket Error # 0; (Neodome username ok) (Finished) [$0000220C]
0 44896390: KillNNTP entered for: Neodome username ok1 (Finished) [$0000220C]

Stunnel log:
2024.01.07 03:57:01 LOG5[0]: Service [Neodome] accepted connection from 127.0.0.1:55555
2024.01.07 03:57:01 LOG5[0]: s_connect: connected 95.216.243.224:563
2024.01.07 03:57:01 LOG5[0]: Service [Neodome] connected remote server from 192.168.1.23:55555
2024.01.07 03:57:01 LOG4[0]: CERT: Pre-verification error: self-signed certificate
2024.01.07 03:57:01 LOG4[0]: Rejected by CERT at depth=0: O=Neodome, CN=neodome.net, emailAddress=ad...@neodome.net
2024.01.07 03:57:01 LOG3[0]: SSL_connect: ssl/statem/statem_clnt.c:1889: error:0A000086:SSL routines::certificate verify failed
2024.01.07 03:57:01 LOG5[0]: Connection closed/reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket

The two main questions are what is a "KillNNTP" in Dialog and
does that error look like the certificate is bad for Neodome?

Is there a way to test the certificate for Neodome?

[VanguardLH]

Your log shows Dialog is connecting to an IP of 127.0.0.1, port 55555.
That's a reserved internal IP address, not one for a site running an
NNTP server. Seems you must be using a local proxy through which you
pipe Dialog connects to a server. Could be that proxy is dead. Could
be to where that proxy points to for external connects is invalid.
Check settings in the proxy on your host (127.0.0.1) to which to tell
Dialog to connect.

Are you using sTunnel, a VPN, or other local proxy with Dialog?

I thought Neodome died, so there'd be no NNTP server to which Dialog (or
your proxy) could connect.

[Ronald]

On Sun, 7 Jan 2024 03:37:46 -0600, VanguardLH wrote:

> Are you using sTunnel, a VPN, or other local proxy with Dialog?

I'm using VPN plus Stunnel with Dialog on Windows.
Just like everyone else does (as Dialog needs Stunned for port 563).

> I thought Neodome died, so there'd be no NNTP server to which Dialog (or
> your proxy) could connect.

I looked up the test commands and I cut and pasted them, so I don't really know what they are telling me but I think the Neodome server has expired.

The odd thing to me is it's supposedly a self-signed certificate.
I don't really know what that means, but how can it expire then?

I don't understand this certificate stuff. Nor signing. Nor expiry.
But here's the output I got from running these commands on Windows.

echo q | openssl s_client -connect news.neodome.net:563 | openssl x509 -noout -enddate | findstr "notAfter"

It reported this result:
depth=0 O = Neodome, CN = neodome.net, emailAddress = ad...@neodome.net
verify error:num=18:self signed certificate
verify return:1
depth=0 O = Neodome, CN = neodome.net, emailAddress = ad...@neodome.net
verify error:num=10:certificate has expired
notAfter=Dec 31 21:59:46 2020 GMT
verify return:1
depth=0 O = Neodome, CN = neodome.net, emailAddress = ad...@neodome.net
notAfter=Dec 31 21:59:46 2020 GMT
verify return:1
notAfter=Dec 31 21:59:46 2020 GMT
DONE

Then I found this command and cut and pasted it into Windows.
openssl s_client -ign_eof -connect news.neodome.net:563

Which reported a long output but I cut out the non errors to result in this.
verify error:num=10:certificate has expired
Verification error: certificate has expired
Verify return code: 10 (certificate has expired)

But Neodome uses a self-signed certificate.
So it's never supposed to expire, right?

I don't know what the output is SUPPOSED to be for a self-signed certificate.
I don't even know what a self-signed certificate even means.

Can you help me make better sense of the output and how to fix it?

[Bernd Rose]

On Sun, 7th Jan 2024 04:11:40 -0500, Ronald wrote:

> Dialog log:
> 5 44896390: Socket Error # 0; (Neodome username ok) (Finished) [$0000220C]
> 0 44896390: KillNNTP entered for: Neodome username ok1 (Finished) [$0000220C]
>
> Stunnel log:
> 2024.01.07 03:57:01 LOG5[0]: Service [Neodome] accepted connection from 127.0.0.1:55555
> 2024.01.07 03:57:01 LOG5[0]: s_connect: connected 95.216.243.224:563
> 2024.01.07 03:57:01 LOG5[0]: Service [Neodome] connected remote server from 192.168.1.23:55555
> 2024.01.07 03:57:01 LOG4[0]: CERT: Pre-verification error: self-signed certificate
> 2024.01.07 03:57:01 LOG4[0]: Rejected by CERT at depth=0: O=Neodome, CN=neodome.net, emailAddress=ad...@neodome.net
> 2024.01.07 03:57:01 LOG3[0]: SSL_connect: ssl/statem/statem_clnt.c:1889: error:0A000086:SSL routines::certificate verify failed
> 2024.01.07 03:57:01 LOG5[0]: Connection closed/reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
>
> The two main questions are what is a "KillNNTP" in Dialog and

Network connection socket is unregistered in the OS active connection table.

> does that error look like the certificate is bad for Neodome?

Yes.

> Is there a way to test the certificate for Neodome?

Yes, for instance with OpenSSL (https://www.openssl.org):
openssl.exe s_client -connect news.neodome.net:563

=> "certificate has expired"

If you don't care about valid certificates for your encrypted connection
you may use this shorted sTunnel configuration. It should still work.

[Neodome]
client = yes
accept = localhost:55555
connect = news.neodome.net:563

HTH.
Bernd

[VanguardLH]

Is a login even required for news.neodome.net?

http://web.archive.org/web/20210618113621/http://neodome.net/

That's the latest archived copy of their web site. Looks like
www.neodome.net disappeared, but their NNTP server still functions. If
a login is not required, why bother with NNTPS at all? Just use the
NNTP connect on port 119, and eliminate using sTunnel.

[Bernd Rose]

On Sun, 7th Jan 2024 04:33:31 -0600, VanguardLH wrote:

> Is a login even required for news.neodome.net?

AFAICT, for posting: yes, for reading: no.

Bernd

[VanguardLH]

Ronald <ron...@nospam.me> wrote:

> VanguardLH wrote:
>
>> Are you using sTunnel, a VPN, or other local proxy with Dialog?
>
> I'm using VPN plus Stunnel with Dialog on Windows.
> Just like everyone else does (as Dialog needs Stunned for port 563).

I don't. I added news.neodome.net using SSL on port 563. I was able to
retrieve a groups list from Neodome, so the connection worked. Also was
able to download articles from alt.computer. I'm not using sTunnel, or
anything else to get SSL connects on port 563 to work in Dialog. I just
enabled the SSL checkbox in the server config in Dialog.

40tude Dialog 2.0.15.41 (beta 38)

>
>> I thought Neodome died, so there'd be no NNTP server to which Dialog (or
>> your proxy) could connect.

I was wrong. Their web site disappeared (www.neodome.net). Last time
it was found per web.archive.org was Jun 18, 2021:

http://web.archive.org/web/20210618113621/http://neodome.net/

I can still do "telnet news.neodome.net 119" to get a connect.

> The odd thing to me is it's supposedly a self-signed certificate.
> I don't really know what that means, but how can it expire then?

Anything you post to Usenet remains public. The only reason to use SSL
is to secure your login credentials. When I created a Neodome account
in Dialog (and clicked the SSL checkbox and specified port 563), I did
not need nor have any login credentials. Looks like Neodome is an
*un*registered Usenet provider (free, no login needed). Since login is
not required, why bother with an encrypted connection?

Why not use port 119 without SSL? I don't see a reason to use an
encrypted connection of a server that stores publicly accessible info.

> echo q | openssl s_client -connect news.neodome.net:563 | openssl x509 -noout -enddate | findstr "notAfter"
>
> It reported this result:
> depth=0 O = Neodome, CN = neodome.net, emailAddress = ad...@neodome.net
> verify error:num=18:self signed certificate
> verify return:1
> depth=0 O = Neodome, CN = neodome.net, emailAddress = ad...@neodome.net
> verify error:num=10:certificate has expired
> notAfter=Dec 31 21:59:46 2020 GMT
> verify return:1
> depth=0 O = Neodome, CN = neodome.net, emailAddress = ad...@neodome.net
> notAfter=Dec 31 21:59:46 2020 GMT
> verify return:1
> notAfter=Dec 31 21:59:46 2020 GMT

I'm no cert guru, either. From the above, the cert is for neodome.net,
and may not be a multi-host cert (I thought a wildcard was used to
denote any host at the domain).

You are connecting to news.neodome.net, not to neodome.net. Their cert
is flawed. It is a self-signed cert; that is, they created it instead
of using a CA (Certificate Authority). My guess is they need to
regenerate their self-signed cert to identify CN = news.neodome.net
which is the host to which you are connecting. They probably instead
get a free site cert from LetsEncrypt.

A self-signed cert does not need to be time ranged, so it won't expire.
However, notice their cert does have an expiration:

notAfter=Dec 31 21:59:46 2020 GMT

Maybe that gets ignored for self-signed certs.

So, it is an expired self-signed certificate

[david]

Using <news:1kgyqw4a...@b.rose.tmpbox.news.arcor.de>, Bernd Rose

wrote:

>> Is a login even required for news.neodome.net?
>
> AFAICT, for posting: yes, for reading: no.

A lot of news servers are that way (for example, news.dizum.net:119).
But you need an account and port 563 to post to them most of the time.

[Ronald]

On Sun, 7 Jan 2024 11:07:58 +0100, Bernd Rose wrote:

> If you don't care about valid certificates for your encrypted connection
> you may use this shorted sTunnel configuration. It should still work.

Thank you for that advice. I don't understand why I even need encryption
since (as Vanguard said) the end result is being posted to the public.

I think it's supposed to protect my login credentials but isn't that what
the VPN is for? I'm always on NordVPN all the time anyway.

> [Neodome]
> client = yes
> accept = localhost:55555
> connect = news.neodome.net:563

Oh my gosh. That actually worked! How did you know how to do that trick?

Stunnel log
2024.01.07 06:28:31 LOG5[1]: Service [Neodome] accepted connection from 127.0.0.1:43503
2024.01.07 06:28:32 LOG5[1]: s_connect: connected 95.216.243.224:563
2024.01.07 06:28:32 LOG5[1]: Service [Neodome] connected remote server from 10.211.1.153:43504
2024.01.07 06:28:51 LOG5[1]: Connection closed: 344 byte(s) sent to TLS, 320 byte(s) sent to socket

Dialog log
3 53998687: Posting message to NNTP server [$00000634]
1 54004625: Reindexing (Order: 3, no filtering) of group 2 with 8910 articles took 47 ms
3 54004562: Posting sent successfully: Article received <###########@neodome.net>; (Finished) [$00000634]

Can you give me a clue as to what that Stunnel log did?
Somehow it still posted WITHOUT needing the certificate to be valid.

Will that method work with all encrypted news servers?

[Bernd Rose]

On Sun, 7th Jan 2024 06:38:18 -0500, Ronald wrote:

> I don't understand why I even need encryption
> since (as Vanguard said) the end result is being posted to the public.
>
> I think it's supposed to protect my login credentials

Yes, mostly for this. And for any MitM not knowing, which articles you are
/reading/ and other such information.

> but isn't that what the VPN is for? I'm always on NordVPN all the time anyway.

No. I don't know, how you configured usage of NordVPN. But either, the NNTP
traffic isn't routed via NordVPN, at all. (If port 563 isn't attached to the
VPN.) Or your login credentials are unprotected, whenever they leave NordVPN
server on their route to the Neodome server. Using a VPN service is _not_ a
replacement for using transport encryption!

>> [Neodome]
>> client = yes
>> accept = localhost:55555
>> connect = news.neodome.net:563
>
> Oh my gosh. That actually worked! How did you know how to do that trick?

That's not a trick. I just removed any lines ensuring, that only connections
to correctly certified servers are permitted.

> Stunnel log
> 2024.01.07 06:28:31 LOG5[1]: Service [Neodome] accepted connection from 127.0.0.1:43503
> 2024.01.07 06:28:32 LOG5[1]: s_connect: connected 95.216.243.224:563
> 2024.01.07 06:28:32 LOG5[1]: Service [Neodome] connected remote server from 10.211.1.153:43504
> 2024.01.07 06:28:51 LOG5[1]: Connection closed: 344 byte(s) sent to TLS, 320 byte(s) sent to socket
>
> Dialog log
> 3 53998687: Posting message to NNTP server [$00000634]
> 1 54004625: Reindexing (Order: 3, no filtering) of group 2 with 8910 articles took 47 ms
> 3 54004562: Posting sent successfully: Article received <###########@neodome.net>; (Finished) [$00000634]
>
> Can you give me a clue as to what that Stunnel log did?
> Somehow it still posted WITHOUT needing the certificate to be valid.

Encryption doesn't need a certificate to be valid. This way, you just can't
be sure, that the target server really /is/ the one you are trying to
connect to. It might be an unfriendly server /impersonating/ the other one.

> Will that method work with all encrypted news servers?

As long as a server does have a valid certificate, you should /not/ lower
the security bars. If problems occur, first contact the provider to have
them fix their end. Only, if this isn't an option, consider lowering the
security requirements. Be sure, that you are able to live with possible
consequences, though.

With Neodome, their NNTP server seems to be nearly abandoned. Therefore,
contacting the admins will probably not lead to a fixed certificate. The
consequences may be lost login credentials and other users posting fake
messages impersonating you. - Your decision. (Maybe, better look for
another Usenet provider...)

Bernd

[Ronald]

On Sun, 7 Jan 2024 14:06:23 +0100, Bernd Rose wrote:

> With Neodome, their NNTP server seems to be nearly abandoned. Therefore,
> contacting the admins will probably not lead to a fixed certificate.

I had sent an email more than a week before asking the question here.

>> Can you give me a clue as to what that Stunnel log did?
>> Somehow it still posted WITHOUT needing the certificate to be valid.
>
> Encryption doesn't need a certificate to be valid. This way, you just can't
> be sure, that the target server really /is/ the one you are trying to
> connect to. It might be an unfriendly server /impersonating/ the other one.

Does that mean I could have omitted stunnel altogether and just used the
40tude dialog user setup with "Host = news.neodome.net" & "Port = 563"?

If I test that out, does it matter if the SSL box is checked or not?
(I never understood what the difference was with or with that SSL checked.)

[Ronald]

On Sun, 7 Jan 2024 08:40:27 -0500, Ronald wrote:

> Does that mean I could have omitted stunnel altogether and just used the
> 40tude dialog user setup with "Host = news.neodome.net" & "Port = 563"?
>
> If I test that out, does it matter if the SSL box is checked or not?
> (I never understood what the difference was with or with that SSL checked.)

I tested posting to Neodome using Dialog without Stunnel.

This failed.
Host: news.neodome.net
Port: 563

SSL: unchecked
Username: abcdefg
Password: xxxxxxx
Allwd. conn.: 2
Use pipelining (unchecked)

This worked.
Host: news.neodome.net
Port: 563
SSL: checked

Username: abcdefg
Password: xxxxxxx
Allwd. conn.: 2
Use pipelining (unchecked)

So Vanguard was correct that Stunnel wasn't needed to post.
But it did not work without checking the Dialog "SSL" checkbox.

What did that Dialog "SSL" checkbox do to make it work?

[Bernd Rose]

On Sun, 7th Jan 2024 08:40:27 -0500, Ronald wrote:

>> Encryption doesn't need a certificate to be valid. This way, you just can't
>> be sure, that the target server really /is/ the one you are trying to
>> connect to. It might be an unfriendly server /impersonating/ the other one.
>
> Does that mean I could have omitted stunnel altogether and just used the
> 40tude dialog user setup with "Host = news.neodome.net" & "Port = 563"?

Maybe and no. Dialog.exe was compiled 2005 and uses (at best) encryption
methods that have been developed until then. (It is a bit more complicated,
because it may profit from /some/ updates to OS encryption functions. But
in the whole, Dialog encryption is stuck in 2005.)

If the NNTP server still supports at least one of these old encryption
methods, then connecting directly to the server on port 563 from Dialog
(with SSL ticked /on/) would work. (Neodome seems to.) Quite a few NNTP
servers disabled all these old (and insecure) encryption methods, though.
With them, direct encrypted connection from Dialog will /not/ work.

Using sTunnel in any case will not only ensure, that encrypted connection
to a server will succeed with contemporary encryption methods. It will also
prevent usage of outdated (insecure) methods. Therefore, even /if/ a server
still permits encrypted connection directly from Dialog, it is better to
use the workaround via sTunnel.

> If I test that out, does it matter if the SSL box is checked or not?
> (I never understood what the difference was with or with that SSL checked.)

The SSL box indicates, whether encryption should be used when sending
information to the target address (server and port) configured inside
Dialog. If you enter the external NNTP server name and its port, you need
to check with the provider, whether encryption is supported or not. Usually,
port 119 means "no encryption" (SSL box off) and port 563 means "encryption"
(SSL box on).

If you enter a local (sTunnel) address, you /could/ encrypt this local
connection, as well. You'd need to configure sTunnel for local encryption,
though, and you'd need to permit the usage of outdated encryption methods
for this, as well. This makes no sense, whatsoever. Therefore, any local
connection (your localhost:55555 for example) should be configured without
encryption (SSL box off). This has no influence on the encryption state
for the outgoing connection to the NNTP server, which /will/ be encrypted
by sTunnel, as long as you don't explicitly tell it to /not/ do it. (Which,
again, wouldn't make any sense...)

Bernd

[D]

using remailers for posting works most of the time ... no account needed

[Ronald]

On Sun, 7 Jan 2024 15:19:58 +0100, Bernd Rose wrote:

>> Does that mean I could have omitted stunnel altogether and just used the
>> 40tude dialog user setup with "Host = news.neodome.net" & "Port = 563"?
>
> Maybe and no. Dialog.exe was compiled 2005 and uses (at best) encryption
> methods that have been developed until then. (It is a bit more complicated,
> because it may profit from /some/ updates to OS encryption functions. But
> in the whole, Dialog encryption is stuck in 2005.)

I understand what you just said as I too had believed Dialog needed to have
Stunnel added in order to do the encryption part.

Dialog does allow me to set news.neodome.net:563 with SSL. And that works.
Even though the certificate (we think) has expired.

Does SSL NOT check certificates to see if they've expired?

> If the NNTP server still supports at least one of these old encryption
> methods, then connecting directly to the server on port 563 from Dialog
> (with SSL ticked /on/) would work. (Neodome seems to.) Quite a few NNTP
> servers disabled all these old (and insecure) encryption methods, though.
> With them, direct encrypted connection from Dialog will /not/ work.

I guess that's what's happening since Neodome on port 563 with SSL works.
But not without SSL (at least in the one set of tests that I ran today).

> Using sTunnel in any case will not only ensure, that encrypted connection
> to a server will succeed with contemporary encryption methods. It will also
> prevent usage of outdated (insecure) methods. Therefore, even /if/ a server
> still permits encrypted connection directly from Dialog, it is better to
> use the workaround via sTunnel.

I agree. I am using Stunnel for other encrypted news servers.

It's just that when you helped me debug the Neodome connection, it turns
out that the Neodome self-signed certificates have apparently expired.

>> If I test that out, does it matter if the SSL box is checked or not?
>> (I never understood what the difference was with or with that SSL checked.)
>
> The SSL box indicates, whether encryption should be used when sending
> information to the target address (server and port) configured inside
> Dialog. If you enter the external NNTP server name and its port, you need
> to check with the provider, whether encryption is supported or not. Usually,
> port 119 means "no encryption" (SSL box off) and port 563 means "encryption"
> (SSL box on).
>
> If you enter a local (sTunnel) address, you /could/ encrypt this local
> connection, as well. You'd need to configure sTunnel for local encryption,
> though, and you'd need to permit the usage of outdated encryption methods
> for this, as well. This makes no sense, whatsoever. Therefore, any local
> connection (your localhost:55555 for example) should be configured without
> encryption (SSL box off). This has no influence on the encryption state
> for the outgoing connection to the NNTP server, which /will/ be encrypted
> by sTunnel, as long as you don't explicitly tell it to /not/ do it. (Which,
> again, wouldn't make any sense...)

I think I see what you're saying SSL does. It's a LOCAL encryption.

So if I checked the Dialog SSL box AND if I used Stunnel, it would be twice
encrypted, is that what I'm hearing you say will be happening?

If the Dialog SSL checkbox is "local encryption", what's Stunnel doing?
Is it doing encryption not locally?

[david]

Using <news:879f4360c37366ed...@dizum.com>, D wrote:

>>A lot of news servers are that way (for example, news.dizum.net:119).
>>But you need an account and port 563 to post to them most of the time.
>
> using remailers for posting works most of the time ... no account needed

I don't get it.
Every time I mention dizum or mixmin someone mentions remailers.

Yet you can READ from both of them using your news reader alone.
No email is ever involved.

It used to be you could POST to both of them also, before the spammers
drove them nuts and their news admins had to turn off posting.

But even then, you could POST to both of them using Dialog & Stunnel.
Email is NEVER involved.

So why do people always bring up "remailers" when I mention mixmin/dizum?
Call me confused.

[Bernd Rose]

On Sun, 7th Jan 2024 10:10:20 -0500, Ronald wrote:

> Dialog does allow me to set news.neodome.net:563 with SSL. And that works.
> Even though the certificate (we think) has expired.

That's not the point. It works, because Dialog doesn't check for expiration
of any server certificate *and* because Neodome still supports outdated and
insecure encryption methods.

> Does SSL NOT check certificates to see if they've expired?

The "SSL" check box is just a name for a setting indicating, that Dialog
should use a connection handshake for an encrypted transmission. In the
background several major encryption methods (SSLv2..SSLv3, TLSv1) with
a multitude of handshake methods, cipher suites, and so on can be chosen.
It is up to the handshake between the NNTP server and your client, which
encryption method is used in the end.

Certificate checking is mostly part of the handshake process and shall
ensure, that connection is established to the correct server and not to
an imposter. Dialog does /some/ checking, but offers more leeway than
most current certificate checking implementations.

There's another risk, btw.: Sometimes current certificate checks fail with
Dialog, because it doesn't have a large enough buffer space reserved for
the certificate data. Very large certificates do not fit, which leads to
wrong checksums and missing certificate data. Connection to servers with
such large certificates will fail, even when they still support some old
encryption methods.

>> The SSL box indicates, whether encryption should be used when sending
>> information to the target address (server and port) configured inside
>> Dialog. If you enter the external NNTP server name and its port, you need
>> to check with the provider, whether encryption is supported or not. Usually,
>> port 119 means "no encryption" (SSL box off) and port 563 means "encryption"
>> (SSL box on).
>>
>> If you enter a local (sTunnel) address, you /could/ encrypt this local
>> connection, as well. You'd need to configure sTunnel for local encryption,
>> though, and you'd need to permit the usage of outdated encryption methods
>> for this, as well. This makes no sense, whatsoever. Therefore, any local
>> connection (your localhost:55555 for example) should be configured without
>> encryption (SSL box off). This has no influence on the encryption state
>> for the outgoing connection to the NNTP server, which /will/ be encrypted
>> by sTunnel, as long as you don't explicitly tell it to /not/ do it. (Which,
>> again, wouldn't make any sense...)
>
> I think I see what you're saying SSL does. It's a LOCAL encryption.

That's not what I wrote. It is a setting, whether encryption should be used
when connecting to the target address shown in the entry fields beside it.
If this is a local IP-address:port combination (e. g. localhost:55555), than
it sets/unsets local encryption. If, OTOH, it is an external IP-address:port
combination (e. g. news.neodome.net:563), than it sets/unset an outgoing

encryption.

> So if I checked the Dialog SSL box AND if I used Stunnel, it would be twice
> encrypted, is that what I'm hearing you say will be happening?

No. If you set SSL in Dialog, then the data would be encrypted in Dialog,
sent encrypted to sTunnel, would be decrypted by sTunnel and afterwards
newly encrypted (most likely with another method) by sTunnel. Then sent
encrypted to the NNTP server, which again needs to decrypt it.

Encryption between Dialog and sTunnel is - of course - superfluous: With
access to your PC the unencrypted data is found on either end of the
connection (Dialog and sTunnel). Nobody will hack into the /transmission/
between Dialog and sTunnel to get to the data...

Bernd

[VanguardLH]

Bernd Rose <b.rose...@arcor.de> wrote:

> VanguardLH wrote:
>
>> Is a login even required for news.neodome.net?
>
> AFAICT, for posting: yes, for reading: no.

Would think it was the other way around: no login needed for reading,
login perhaps required for posting.

Their archived web page says:
- 3 of their servers are read only for non-neodome.* newsgroups, and
require login (user=test, pass=test) to post only to their neodome.*
newsgroups.
- 2 of those look to be for onion/Tor connects.
- The 4th server (top of their list) doesn't mention any restriction on
reading or posting for any newsgroup, and no mention of login.

Their web site disappeared a couple years ago, so I have no idea if
their conditions on use have changed since then, but no way to check
since they don't have a web site anymore. Maybe they put announcements
in their own neodome.* newsgroups.

[VanguardLH]

I figured sTunnel was superflous since Dialong can use SSL to make
connections. The point of sTunnel is to use it with programs that don't
support secured connnections, like really old NNTP, email, or other
clients too old to have added SSL, or they are only supporting SSL3
which got deprecated, or encryption algorithms that got dropped.

[Bernd Rose]

On Sun, 7th Jan 2024 10:09:11 -0600, VanguardLH wrote:

> Bernd Rose <b.rose...@arcor.de> wrote:
>
>> VanguardLH wrote:
>>
>>> Is a login even required for news.neodome.net?
>>
>> AFAICT, for posting: yes, for reading: no.
>
> Would think it was the other way around: no login needed for reading,
> login perhaps required for posting.

That's what I wrote. ;-)

Bernd

[Bernd Rose]

On Sun, 7th Jan 2024 10:16:29 -0600, VanguardLH wrote:

> I figured sTunnel was superflous since Dialong can use SSL to make
> connections. The point of sTunnel is to use it with programs that don't
> support secured connnections, like really old NNTP, email, or other
> clients too old to have added SSL, or they are only supporting SSL3
> which got deprecated, or encryption algorithms that got dropped.

*All* encryption methods supported by Dialog are depreciated. The most
current version supported is TLS_1.0. Even the (unsupported) TLS_1.1
is already depreciated.

Bernd

[D]

On Sun, 7 Jan 2024 08:15:14 -0700, david <th...@is.invalid> wrote:
>Using <news:879f4360c37366ed...@dizum.com>, D wrote:

there are dozens of free nntp news servers, and about twenty-five public
remailers (11 mix w/ 5 exits, 14 yamn w/6 exits) which usually work well
and are very popular with innumerable users, often for posting to usenet
newsgroups such as this one; used judiciously with tor connections makes
for the safest and easiest way to use any newsreader clients, free agent,
40tude dialog, mesnews etc. i've been using remailers exclusively since
1998; currently using omnimix, tor browser, 40tude dialog and free agent

[VanguardLH]

I had not yet had my morning coffee.

However, from their archived web page, looks like one of their servers
(the most used one since the others look for Onion/Tor access) requires
no login for read/write access.

news.neodome.net:
119 - read/write
119 (STARTTLS) - read/write
563 (SSL) - read/write

For the /other/ servers, a login was specified:

test login: test
test password: test

When I added Neodome to Dialog and tested access (read), I needed no
login credentials to read. I wasn't interested in using Neodome, so I
didn't try submitting an article (write).

I actually have a filter to ignore-flag any posts originating at Neodome
(and also ignore any subthreads to an ignore-flagged article), and use a
default view of Hide Ignored. I don't keep messages very long in the
client (purged after 60 days). A search on "neodome" in headers didn't
find any still left in my Dialog. Not sure anyone still uses Neodome.
Not what they peer, but what gets submitted to them as the injection
node.

[VanguardLH]

Hmm, guess the encryption schemes (cipher suites) used by Neodome are
also deprecated. Old matching on old.

SSL3 and TLS1.0 are the same, but made non-compatible by different
handshaking schemes. When SSL3 got deprecated, so did TLS1.0.

While I can use ssllabs.com to analyze certs for a web site (HTTP[S]), I
can't use them to analyze the cert at an NNTP site. I'd rather use the
properties of a cert to analyze it instead of trying to decipher
Dialog's logs.

Since news.neodome.net does not require a login, and since everything
posted to Usenet is public, don't see why SSL/TLS is even needed to use
Neodome, or any other Usenet provider that does not require a login
(e.g., BOFH paganini, AIOE until they died).

[VanguardLH]

david <th...@is.invalid> wrote:

> Using <news:879f4360c37366ed...@dizum.com>, D wrote:
>
>>>A lot of news servers are that way (for example, news.dizum.net:119).
>>>But you need an account and port 563 to post to them most of the time.
>>
>> using remailers for posting works most of the time ... no account needed
>
> I don't get it.
> Every time I mention dizum or mixmin someone mentions remailers.

For mixmin: http://news.mixmin.net/banana/m2n.html

They *do* operate a mail-to-news gateway. As you mention, the
news.mixmin.net server is read-only, so only good for lurking, not for
participating in Usenet, leaving only their M2N gateway to participate.

[Ronald]

On Sun, 7 Jan 2024 13:15:09 -0600, VanguardLH wrote:

>> I don't get it.
>> Every time I mention dizum or mixmin someone mentions remailers.
>
> For mixmin: http://news.mixmin.net/banana/m2n.html
>
> They *do* operate a mail-to-news gateway. As you mention, the
> news.mixmin.net server is read-only, so only good for lurking, not for
> participating in Usenet, leaving only their M2N gateway to participate.

I think "david" missed the point of the post from "D <J@M>" which,
I think, was that all these problems with encrypted servers can be
worked around by using anonymous remailer software instead of nntp.

At least I think that based on what he said, and on his headers.
Can you please look at the headers from "D <J@M>" for me please?

Subject: Re: (Dialog) How do I debug a 40tude "socket error" ...
Injection-Info: neodome.net; posting-account="mail2news"; key="###";
mail-complaints-to="ab...@neodome.net"
Comments: This message did not originate from the Sender address above.
It was remailed automatically by anonymizing remailer software.
Please report problems or inappropriate use to the remailer
administrator at <ab...@dizum.com>.
Comments: This message was transferred to Usenet via mail2news gateway at
<mail...@neodome.net>. Please send questions and concerns to
<ad...@neodome.net>. Report inappropriate use to <ab...@neodome.net>.
Injection-Date: Sun, 7 Jan 2024 14:35:01 +0000 (UTC)
From: D <J@M>
Message-ID: <879f4360c37366ed...@dizum.com>
Date: Sun, 7 Jan 2024 15:34:50 +0100 (CET)
Newsgroups: news.software.readers
Sender: Nomen Nescio <nob...@dizum.com>
{blank line}

using remailers for posting works most of the time ... no account needed

Since _both_ dizum & neodome are in that header, I can't tell if
"D <J@M>" mailed his original to dizum or to neodome (maybe dizum?).

Can you tell which is the server that "D <J@M>" remailed this to?
I never used a remailer myself.

I think "D <J@M>" was trying to tell us that all these problems we've
been having with certificates for neodome and also the fact that both
dizum and mixmin recently closed down nntp posting due to spammers
(AFAICT) can be immediately resolved by using anonymous remailers.

I'd like to test out the suggestion from "D <J&M>" to try remailers
as a failsafe whenever the encryption for neodome expires again.

Do you know how to send a test message using an anonymous remailer
from Windows to any of those news servers "D <J@M>" seems to have used?

[Ronald]

On Sun, 7 Jan 2024 12:38:09 -0600, VanguardLH <V...@nguard.LH> wrote

> I actually have a filter to ignore-flag any posts originating at Neodome

I've been using Neodome with Dialog & sTunnel for years but I think what
you are filtering out are the anonymous remailers that "D <J@M>" tested.

What "D <J@M>" was trying to tell us, I think, was that the next time the
certificate expires, another workaround (to the one Bernd suggested) is to
post to Neodome using its anonymous remailer but I've never done that.

> news.neodome.net:
> 119 - read/write
> 119 (STARTTLS) - read/write
> 563 (SSL) - read/write
>
> For the /other/ servers, a login was specified:
>
> test login: test
> test password: test
>
> When I added Neodome to Dialog and tested access (read), I needed no
> login credentials to read.

Thank you for looking the nntp posting details up as I opened my Neodome
posting account years ago which (I have been using almost daily since).

The strange thing is posting has been working up until about a month ago,
but when I look at the self-signed certificate expiry, it's 3 years ago!

echo q | openssl s_client -connect news.neodome.net:563 | openssl x509 -noout -enddate | findstr "notAfter"

verify error:num=10:certificate has expired
notAfter=Dec 31 21:59:46 2020 GMT

How can that possibly make any sense that I've been posting with Dialog and
sTunnel (using Bernd's casing) to Neodome 563 until less than about a month
ago and yet the Neodome self-signed certificate had expired 3 years ago?

> I wasn't interested in using Neodome, so I didn't try submitting an article (write).

Certainly up until a few weeks ago, with an account, posting worked using
Dialog set up to use sTunnel (which checked certs at news.neodome.net 563).

Only recently did the certificate check fail (even as the certificate seems
to have expired 3 years ago) but using the workarounds provided, it worked.

Workaround #1: (Tell sTunnel to NOT check the certificate!)
[Neodome]
; This skips checking of the certificate expiry date"

client = yes
accept = localhost:55555
connect = news.neodome.net:563

Workaround #2: (Tell Dialog to NOT get sTunnel involved & use 563 SSL!)
Dialog Host: news.neodome.net
Dialog Port: 563
Dialog SSL: checked
Dialog Username: abcdefg
Dialog Password: xxxxxxx
Dialog Allwd. conn.: 2
Dialog Use pipelining (unchecked)

> news.neodome.net:
> 119 - read/write
> 119 (STARTTLS) - read/write
> 563 (SSL) - read/write

Oh! I did not know Neodome might _write_ to port 119, so let me try it.
Dialog Host: news.neodome.net
Dialog Port: 119
Dialog SSL: unchecked
Dialog Username: abcdefg
Dialog Password: xxxxxxx
Dialog Allwd. conn.: 2
Dialog Use pipelining (unchecked)

0 118434281: KillNNTP left for: neodome uname (Finished) [$00001EA4]
5 118434281: Posting article failed: Encryption required; (neodome uname) (Finished) [$00001EA4]

Just to cover all bases, I also checked the SSL box in the next test.
Dialog Host: news.neodome.net
Dialog Port: 119
Dialog SSL: checked
Dialog Username: abcdefg
Dialog Password: xxxxxxx
Dialog Allwd. conn.: 2
Dialog Use pipelining (unchecked)

0 118685015: KillNNTP left for: neodome uname (Finished) [$00002508]
5 118685015: Posting article failed: Error while receiving. Connection closed. (neodome uname) (Finished) [$00002508]

I don't know what "STARTTLS" means though, so I didn't test it.

[Ronald]

On Sun, 7 Jan 2024 12:46:42 -0600, VanguardLH wrote:

> Since news.neodome.net does not require a login, and since everything
> posted to Usenet is public, don't see why SSL/TLS is even needed to use
> Neodome, or any other Usenet provider that does not require a login
> (e.g., BOFH paganini, AIOE until they died).

Bearing in mind this is all about get 40Tude Dialog properly set up....

I'll let Bernd respond to the other technical issues you brought up but I
do want to confirm I tested everthing you suggested since I do have a valid
Neodome posting account.

Assuming you want to post to the typical Usenet text newsgroups....

I think the summary (at the level I know it) is something like this.
a. You can _read_ from Neodome servers using (based on your tests anyway)

Dialog Host: news.neodome.net
Dialog Port: 119
Dialog SSL: unchecked

Dialog Username: leave blank
Dialog Password: leave blank

Dialog Allwd. conn.: 2
Dialog Use pipelining (unchecked)

b. You can't _post_ to Neodome without an account (no longer offered)

Dialog Host: news.neodome.net
Dialog Port: 563
Dialog SSL: checked

Dialog Username: your_uname
Dialog Password: your_passwd

Dialog Allwd. conn.: 2
Dialog Use pipelining (unchecked)

But that uses the Dialog old encryption standards.

c. You _should_ post to Neodome (with an account) using sTunnel encryption
Dialog Host: 127.0.0.1 [You can use "localhost" if you like]
Dialog Port: 60563 [You can choose any unused port you like]
Dialog SSL: unchecked
Dialog Username: your_uname
Dialog Password: your_passwd

Dialog Allwd. conn.: 2
Dialog Use pipelining (unchecked)

[Neodome]
; Use this as it checks the self-signed certificate for validity
client = yes
accept = 127.0.0.1:60563
connect = news.neodome.net:563
verify = 0
verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.neodome.net
OCSPaia = yes

d. In the case of an expired certificate, this is the best workaround
Dialog Host: 127.0.0.1 [You can use "localhost" if you like]
Dialog Port: 60563 [You can choose any unused port you like]
Dialog SSL: unchecked
Dialog Username: your_uname
Dialog Password: your_passwd

Dialog Allwd. conn.: 2
Dialog Use pipelining (unchecked)

; Workaround #1: (Tell sTunnel to NOT check the certificate!)
; sTunnel will use the latest encryption standards (Dialog will not)
[Neodome]
; This skips encryption for when the certificate has expired
client = yes
accept = localhost:65555
connect = news.neodome.net:563

e. If all else fails, apparently you can post using anonymous remailers
If you know how to post to Neodome that way, please add it here.

Bernd & Vanguard,
Does that look accurate yet as a summary of how to post to Neodome?

[Ronald]

On Sun, 7 Jan 2024 05:08:19 -0600, VanguardLH wrote:

> You are connecting to news.neodome.net, not to neodome.net. Their cert
> is flawed. It is a self-signed cert; that is, they created it instead
> of using a CA (Certificate Authority). My guess is they need to
> regenerate their self-signed cert to identify CN = news.neodome.net
> which is the host to which you are connecting. They probably instead
> get a free site cert from LetsEncrypt.
>
> A self-signed cert does not need to be time ranged, so it won't expire.
> However, notice their cert does have an expiration:
>
> notAfter=Dec 31 21:59:46 2020 GMT
>
> Maybe that gets ignored for self-signed certs.
>
> So, it is an expired self-signed certificate

I finally figured out what happened most likely!

[Neodome]
client = yes
accept = 127.0.0.1:62563

connect = news.neodome.net:563
verify = 0
;verifyChain = yes
;CAfile = ca-certs.pem
;checkHost = news.neodome.net
;OCSPaia = yes

I went back to the original email from the Neodome admin about the setup,
and lo and behold the ONLY thing the admin told me to use was the "verify =
0" line (which he said was because it was a self-signed certificate).

He never gave me the rest of those lines.
I must have boilerplated them, and commented them out at that time.

This probably explains what happened.

The certificate probably was expired all along.
I probably had the correct commented out entries for a long time.

At some point, I uncommented those entries (not understanding them).
That's almost certainly when the error occurred without me noticing.
Since then, it has failed.

Just now I set the file back to what it was in that backup.
That "verify = 0" (without the others) worked to post to Neodome!

Of course, sTunnel gives the warning:
Service [Neodome] needs authentication to prevent MITM attacks

But it's working again.
Thank you for reminding me of what happened a few weeks ago.

This one can be chalked up to user error.

[VanguardLH]

D posts using dizum/mixmin. I have filters that get rid of all posts
that originate from those sewer sources. Hey, it's not me that titled
them sewer. Often "sewer" is included in the name of the injection node
in the PATH header. I filter out posts that are submitted to mixmin as
the injection node, but I do not filter out when articles have been
peered through mixmin (which means it is not the injection node).
mixmin is a large source of trolls, malcontents, peuriles, and other
untoward posters. mixmin and Google Groups are sources of a lot of
noise in Usenet. On Feb 24, the GG noise will disappear. AIOE (died
earlier this year) and Paganini are *un*registered Usenet providers, and
also were/are large sources of Usenet noise, as well as other
unregistered free Usenet providers that I filter out.

I wouldn't see D's posts since I filter out mixmin-sourced articles.
You did not show the PATH header. The Message-ID header indicates D
submitted to a dizum server, and the other headers indicate he used
e-mail to send his message to the dizum server. Using the MID header:

http://al.howardknight.net/?STYPE=msgid&MSGI=%3C879f4360c37366ed1912e3a3261b1150%40dizum.com%3E

shows a PATH header of:

Path:
...!1.us.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!usenet.goja.nl.eu.org!weretis.net!feeder8.news.weretis.net!news.neodome.net!mail2news

The injection node (where D submitted) is neodome.net, but I don't know
if that was using news.neodome.net or using the mail-to-news gateway
with D sending e-mail to neodome. One of the Comments headers (which is
NOT a standard header name, and should've been called X-Comments) also
says the neodome M2N gateway was used.

Despite D using @dizum.com as the domain in his MID, he made that up.
Even your client lets you specify what strings to use in the MID header.
If your client doesn't specify a MID header, the server to where you
submit will add its own. If you specify a MID header, the server is
supposed to step aside to use the one the client specified unless there
is a MID conflict.

I filter out remailers. I filter out neodome. I'm not unique. You
going to remailers will likely mean you get a reduced audience.

[Bernd Rose]

On Mon, 8th Jan 2024 00:30:00 -0500, Ronald wrote:

> I don't know what "STARTTLS" means though, so I didn't test it.

It is an (alternative) method to initiate a handshake for encryption. Indy,
the network access library used by Dialog, first introduced support for this
with v10. The latest Dialog version was compiled with Indy v9 and therefore
does /not/ support it.

You should be able to connect to Neodome port 119 with STARTTLS with sTunnel
as an intermediate.

Bernd

[Bernd Rose]

On Mon, 8th Jan 2024 05:49:26 -0500, Ronald wrote:

> I finally figured out what happened most likely!
>
> [Neodome]
> client = yes
> accept = 127.0.0.1:62563
> connect = news.neodome.net:563
> verify = 0
> ;verifyChain = yes
> ;CAfile = ca-certs.pem
> ;checkHost = news.neodome.net
> ;OCSPaia = yes
>
> I went back to the original email from the Neodome admin about the setup,
> and lo and behold the ONLY thing the admin told me to use was the "verify =
> 0" line (which he said was because it was a self-signed certificate).

The "verify = X" is an outdated sTunnel option and replaced by a couple
of other options, that are more descriptive (like "verifyChain = yes/no").

Setting "verify = 0" means to request a certificate, but do no checking,
at all. A better way to deal with a self-signed certificate would be, to
download it from a secure location and keep it locally as peer-Neodome.pem
(or any other name). Then use a sTunnel configuration entry like:

[Neodome]
client = yes
accept = 127.0.0.1:62563
connect = news.neodome.net:563

verifyPeer = yes
CAfile = peer-Neodome.pem

As long as the certificate is unchanged on the server, encrypted connection
would be established by sTunnel.

To get the certificate in its current state, you can use the above sTunnel
settings without the last 2 lines. Connect once to Neodome and use the
sTunnel right mouse menu entry "Save Peer certificate -> peer-Neodome.pem"
to retrieve the certificate into the local sTunnel certificate store. (This
is inside the <config> subfolder of the main sTunnel directory or somewhere
in the virtual store for sTunel.) Afterwards, add the last 2 lines to
ensure the verification process. Please note, that in your case this will
fail, because expired certificates are not acceptable for the verification!

Another notice: Saving a certificate will be grayed out, as long as there
was no recent connection to the server.

Bernd

[immibis]

On 1/7/24 04:58, Ronald wrote:
> (What is a Dialog socket error anyway?)

Read it as "connection error", i.e. an incredibly useless message that
doesn't say very much.

"sockets" are the interface that most operating systems have to allow
programs to create network connections. "something went wrong with a
socket" means "something went wrong with a connection".

[Ronald]

On Mon, 8 Jan 2024 17:35:18 +0100, Bernd Rose wrote:

> You should be able to connect to Neodome port 119 with STARTTLS with sTunnel
> as an intermediate.

I'll try that, where sTunnel supports STARTTLS apparently.
https://www.stunnel.org/mailman3/hyperkitty/list/stunne...@stunnel.org/thread/ENK5JRYVFGJ4ZO25DHKQ7Y6EE4YA3RPC/

But I can't find any nntp examples for the setup of the stunnel.conf file.
https://www.google.com/search?q=stunnel.conf+example+nntp+starttls

[Bernd Rose]

[Neodome]
client = yes
accept = 127.0.0.1:55555
connect = news.neodome.net:119
protocol = nntp

should work. Adding any verification (verifyPeer or verifyChain) will fail,
though, because this will (again) trigger the certificate expiration.

Explanation:
If you are able to connect through sTunnel to a server, the connection will
always be encrypted. (Although, with the right setting, it is possible to
use "null encryption" [aka a non-encrypting "encryption" method].) Telling
sTunnel to connect with protocol NNTP on port 119 leads to a handshake with
STARTTLS.

Bernd

[Ronald]

On Tue, 9 Jan 2024 18:47:57 +0100, Bernd Rose <b.rose...@arcor.de> wrote

>> But I can't find any nntp examples for the setup of the stunnel.conf file.
>> https://www.google.com/search?q=stunnel.conf+example+nntp+starttls
>
> [Neodome]
> client = yes
> accept = 127.0.0.1:55555
> connect = news.neodome.net:119
> protocol = nntp
>
> should work. Adding any verification (verifyPeer or verifyChain) will fail,
> though, because this will (again) trigger the certificate expiration.
>
> Explanation:
> If you are able to connect through sTunnel to a server, the connection will
> always be encrypted. (Although, with the right setting, it is possible to
> use "null encryption" [aka a non-encrypting "encryption" method].) Telling
> sTunnel to connect with protocol NNTP on port 119 leads to a handshake with
> STARTTLS.

Thank you for showing me why all the googling in the world didn't find the
"protocol=STARTTLS" command that I had tested & tried & which failed on me.

Your exact port 119 STARTTLS configuration file worked perfectly with Dialog.
; Dialog Host: 127.0.0.1
; Dialog Port: 65535 (pick any unused port between 49152 & 65535)
; Dialog SSL: unchecked
; Dialog Username: (required)
; Dialog Password: (required)
; Dialog Allwd. conn.: 2
; Dialog Use pipelining (unchecked)
[Neodome]
client = yes
accept = 127.0.0.1:65535

connect = news.neodome.net:119
protocol = nntp

I don't understand what comes out of the sTunnel log file though.

Here's the sTunnel log for test message number 1.
LOG5[4]: Service [Neodome] accepted connection from 127.0.0.1:61463
LOG5[4]: s_connect: connected 95.216.243.224:119
LOG5[4]: Service [Neodome] connected remote server from 10.211.1.25:61464
LOG5[4]: Connection closed: 1538 byte(s) sent to TLS, 246 byte(s) sent to socket

Here's the sTunnel log for test message number 2.
LOG5[0]: Service [Neodome] accepted connection from 127.0.0.1:40720
LOG5[0]: s_connect: connected 95.216.243.224:119
LOG5[0]: Service [Neodome] connected remote server from 10.211.1.145:40721
LOG5[0]: Connection closed: 2213 byte(s) sent to TLS, 246 byte(s) sent to socket

First line in the sTunnel log file (accepted):
I never specified "127.0.0.1:61463" or "127.0.0.1:40720".

Third line in the sTunnel log file (connected):
I don't know what "10.211.1.25:61464" or "10.211.1.145:40721"

But it works!

[Ronald]

Thank you for that advice as the Stunnel "Save Peer Certificate" instance
does not last long (as you said it wouldn't) after you've posted articles.
Stunnel: Save Peer Certificate -> Peer-Neodome2.pem
If you've just posted, for example, it will not be grayed out.
But if you reload the configuration file, it instantly grays out.

When it's not grayed out, up comes a box saying:
Stunnel 5.69 on Win64
Peer certificate change has been saved.
Add the following lines to section [Neodome2]:
CAfile = peer-Neodome2.pem
verifyPeer = yes
to enable cryptographic authentication.
Then reload stunnel configuration file.

I didn't test adding it because, as you noted, it will fail on this
particular situation because the Neodome certificate has long expired.

Anyway, if others are using Neodome with Dialog (probably not likely), here
are the four different test suggestions from Bernd & Vanguard that worked.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;{Neodome} stunnel.conf
; Use a different port for each identity between 49152 & 65535
; Stunnel log will always report at least these next four lines:
; Reading configuration from file (path)\stunnel.conf
; UTF-8 byte order mark detected
; FIPS mode disabled
; Configuration successful
; Like it or not, posting to news.neodome.net requires a login/password
; Like it or not, news.neodome.net requires at least a 10-char passwd
; Like it or not, the news.neodome.net certificate is self-signed
; Like it or not, the news.neodome.net certificate expired in 12/2020
; Like it or not, news.neodome.net REQUIRES encryption when posting
; Like it or not, Dialog (circa 2005) uses old encryption standards
; Like it or not, news.neodome.net won't accept Dialog port 119
; Like it or not, news.neodome.net won't accept Dialog port 119 SSL
; Like it or not, news.neodome.net won't accept Dialog port 563
; But news.neodome.net will accept Dialog port 563 with Dialog SSL
; Like it or not, Dialog port 563 SSL uses old encryption standards
; These four tests suggested by Bernd & Vanguard worked in Jan 2024
; 1. news.neodome.net accepts Dialog port 563 SSL posts
; 2. news.neodome.net accepts sTunnel port 119 STARTTLS posts
; 3. news.neodome.net accepts sTunnel port 563 posts (ignoring the cert)
; 4. news.neodome.net accepts sTunnel port 563 posts (acknowledging cert)
; Each solution below is tested workaround thanks to Bernd Rose & Vanguard
; Like it or not, Dialog obfuscates or omits some identify information
; So you may want to save that identify information here in stunnel.conf
; Neodome Identity: (archive your real email address here if you like)
; Dialog Identity: (archive your Dialog email address here if you like)
; Dialog Username = (archive your Dialog username here if you like)
; Dialog Password = (archive your Dialog password here if you like)
; System timezone: (archive your system timezone here if you like)
; Like it or not, SSL often cares about accurate time zone matching
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;{Neodome1}
; This method sets Dialog to use Dialog port 563 SSL encryption
; 40Tude Dialog will NOT use the latest encryption standards.
; sTunnel is not involved so the stunnel.conf should be empty
; Dialog Host: news.neodome.net

; Dialog Port: 563
; Dialog SSL: checked

; Dialog Username: (required)
; Dialog Password: (required)
; Dialog Allwd. conn.: 2
; Dialog Use pipelining (unchecked)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;{Neodome2}
; This method sets Dialog to use sTunnel port 119 STARTTLS.
; You'd think it wouldn't require a password, but it does.
; If you are able to connect through sTunnel to a server,
; that connection will always be encrypted (e.g., as STARTTLS).
; (Although, with the right setting, it is possible to use
; "null encryption" [aka a non-encrypting "encryption" method])
; Setting sTunnel to connect with protocol NNTP on port 119
; leads to a handshake with STARTTLS by default
; Like it or not, you'll see these sTunnel warnings with this entry
; LOG3[main]: No trusted certificates found
; LOG4[main]: Service [Neodome2] needs authentication to prevent MITM attacks

; Dialog Host: 127.0.0.1
; Dialog Port: 65535 (pick any unused port between 49152 & 65535)
; Dialog SSL: unchecked
; Dialog Username: (required)
; Dialog Password: (required)
; Dialog Allwd. conn.: 2
; Dialog Use pipelining (unchecked)

; For self-signed certificates that have not expired, a good way to
; deal with them is to download them & they will be checked against
; the existing non-expired self-signed certificate (which has no chain).
; In Stunnel, if you've recently posted, you can do the following:
; Stunnel: Save Peer Certificate -> Peer-Neodome2.pem
; Up comes a box saying:
; Stunnel 5.69 on Win64
; Peer certificate change has been saved.
; Add the following lines to section [Neodome2]:
; CAfile = peer-Neodome2.pem
; verifyPeer = yes
; to enable cryptographic authentication.
; Then reload stunnel configuration file.
; This approach will fail for neodome but only because it is expired
[Neodome2]
client = yes

accept = 127.0.0.1:65535
connect = news.neodome.net:119
protocol = nntp

; CAfile = peer-Neodome2.pem
; verifyPeer = yes
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;{Neodome3}
; This method sets Dialog to use sTunnel port 563 encryption
; Where this method does not even touch the certificate
; It's probably the best option because it uses current encryption
; Dialog Host: 127.0.0.1
; Dialog Port: 49152 (pick any unused port between 49152 & 65535)

; Dialog SSL: unchecked
; Dialog Username: (required)
; Dialog Password: (required)
; Dialog Allwd. conn.: 2
; Dialog Use pipelining (unchecked)

; Like it or not, you'll see these sTunnel warnings with this entry
; LOG3[main]: No trusted certificates found
; LOG4[main]: Service [Neodome3] needs authentication to prevent MITM attacks
; [Neodome3]
; client = yes
; accept = 127.0.0.1:49152
; connect = news.neodome.net:563
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;{Neodome4}
; This is a very minor variation on the method #3 tested above.
; This method sets Dialog to use sTunnel port 563 encryption
; Where this method requires but does not check the certificate
; The "verify = 0" was initially suggested by the Neodome admin
; The "verify = 0" requests a certificate but does not check it
; Dialog Host: 127.0.0.1
; Dialog Port: 49153 (pick any unused port between 49152 & 65535)

; Dialog SSL: unchecked
; Dialog Username: (required)
; Dialog Password: (required)
; Dialog Allwd. conn.: 2
; Dialog Use pipelining (unchecked)

; Like it or not, you'll see these sTunnel warnings with this entry
; LOG3[main]: No trusted certificates found
; LOG4[main]: Service [Neodome4] needs authentication to prevent MITM attacks
;[Neodome4]
; client = yes
; accept = 127.0.0.1:49153
; connect = news.neodome.net:563
; verify = 0
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

[Bernd Rose]

On Wed, 10th Jan 2024 00:54:19 -0500, Ronald wrote:

> [Neodome]
> client = yes
> accept = 127.0.0.1:65535
> connect = news.neodome.net:119
> protocol = nntp> I don't understand what comes out of the sTunnel log file though.
>
> Here's the sTunnel log for test message number 1.
> LOG5[4]: Service [Neodome] accepted connection from 127.0.0.1:61463
> LOG5[4]: s_connect: connected 95.216.243.224:119
> LOG5[4]: Service [Neodome] connected remote server from 10.211.1.25:61464
> LOG5[4]: Connection closed: 1538 byte(s) sent to TLS, 246 byte(s) sent to socket
>
> Here's the sTunnel log for test message number 2.
> LOG5[0]: Service [Neodome] accepted connection from 127.0.0.1:40720
> LOG5[0]: s_connect: connected 95.216.243.224:119
> LOG5[0]: Service [Neodome] connected remote server from 10.211.1.145:40721
> LOG5[0]: Connection closed: 2213 byte(s) sent to TLS, 246 byte(s) sent to socket
>
> First line in the sTunnel log file (accepted):
> I never specified "127.0.0.1:61463" or "127.0.0.1:40720".

For a connection from Dialog to sTunnel to Neodome you need 4 sockets
(aka pairs of IP-address and port). For your test_message_1 these are:

127.0.0.1:61463 ... local Dialog port for connection to/from sTunnel
-> randomly chosen by Dialog and the OS
127.0.0.1:65535 ... local sTunnel port for connection to/from Dialog
-> predefined by you (Dialog and sTunnel settings)
10.211.1.145:61464 ... local sTunnel port for connection to/from Neodome
-> IP address is your remotely visible IP
-> next free local port chosen by sTunnel and the OS
95.216.243.224:119 ... remote Neodome port for connection to/from sTunnel
-> IP address is remote Neodome IP
-> fixed setting of Neodome server (standard port)

HTH.
Bernd